Adds a new generator option useResponseEntity (default true) for kotlin-spring (identical option exists in java-spring). When disabled, controller methods return the model type directly instead of wrapping in ResponseEntity<>, and @ResponseStatus is added to preserve the HTTP status. (fixes #21833)

Also replaces the (very recently introduced by me) option declarativeInterfaceWrapResponses which is thus removed as the useResponseEntity can now control both and it does not make sense to keep both in place. However functionality depending on that option has not been yet released in any version other than SNAPSHOT.

Changes:

• Introduced useResponseEntity config option. (default true)
• Updated templates to conditionally wrap responses in ResponseEntity or add @ResponseStatus.
• Adjusted imports to include org.springframework.http.ResponseEntity only when needed.
• Preserves backward compatibility; default behavior remains unchanged.
• remove "async" and "responseWrapper" from template as these are not supported by kotlin-spring generator - I presume this was ported over by accident when the kotlin-spring generator templates were bootstrapped by copied java-spring code.
• put interface/controller method params on new lines to prevent super-long method signatures that make it complicated to reference the generated code in practice
• fix incorrect double spaces in generated methods, fix spaces before commas. General cleanup

Motivation:
Provides flexibility for teams preferring direct model returns, aligning kotlin-spring with Java Spring generator capabilities and simplifying generated controller/interface signatures.

Breaking changes
This causes no breaking changes as the default behavior is unchanged. The only minor breaking change is the removal of declarativeInterfaceWrapResponses option. The behavior controlled by this option is now also tied to the new useResponseEntity option.

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package || exit
  ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
  ./bin/utils/export_docs_generators.sh || exit
  

  (For Windows users, please run the script in WSL)
  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
• File the PR against the correct branch: master (upcoming 7.x.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)
• If your PR solves a reported issue, reference it using GitHub's linking syntax (e.g., having "fixes #123" present in the PR description)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request. - Tagging @karismann, @Zomzog, @andrewemery, @4brunu, @yutaka0m, @stefankoppier, @e5l